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PUBLISHER'S COLUMN 



Summer is here. Lazy days should abound but 
not at FIG and FORTH DIMENSIONS Individuals 
and groups are working hare on Standards and 
Cases. Soon there will be announcements and 
printing of these efforts. In tact, if everything works 
out right, the next issue of FORTH DIMENSIONS 
will be the big one that everyone has been waiting 
for (have you renewed your subscription and 
membership?). This doesn't mean that we aren't 
eager for more articles and letters from members, 
send them. More issues are in the works 

Now that we have a few issues of the new looking 
FORTH DIMENSIONS under our belt, we'd like to 
have your suggestions about improvements and 
additional information. Do you want more tech- 
nical material? More beginning mpuf More new 
product information? More??''^'' Let us know. 
Remember your inputs are what make FORTH 
DIMENSIONS. 

Have a nice summer. Renew if you haven't 
already. 

Roy Martens 



LYONS' DEN 



HISTORICAL PERSPECTIVE = 



FORTH was created by Mr. Charles H. Moore in 
1969 at the National Radio Astronomy Observa- 
tory, Charlottesville, VA. It was created out of 
dissatisfaction with available programming tools, 
especially for observatory automation. 

Mr. Moore and several associates formed 
FORTH, Inc. in 1973 for the purpose of licensing 
and support of the FORTH Operating System and 
Programming Language, and to supply applica- 
tion programming to meet customers' unique 
requirements. 

The Forth Interest Group is centered in Northern 
California, although our membership of 1100 is 
world-wide. It was formed in 1978 by FORTH 
programmers to encourage use of the language by 
the interchange of ideas through seminars and 
publications. 



While listening to vhe tapes cf the FORTH 
Convention (available from Audio Village, P.O. 
Box 291. Bloomington, lA 47402, $16.00 for four 
tapes) I noticed puzzlement over how to com- 
municate concisely the nature of FORTH, that is, 
what single term— operating system, compiler, 
interpreter— indentifies the class to which it 
belongs. How about referring to FORTH as a Meta 
Interpreter— a program for generating an inter- 
preter (the application) to provide an interactive 
tool for solving application specific problems 
(sometimes referred to as JOL's, job-oriented- 
languages)? Other members cf this class are LISP 
and an obscure IBM system called PLAi\', as well 
as APL. FORTH has unique features distinguish- 
ing it from other members of this class, being more 
optimized for arithmetic than LISP, for example, 
and being more compact and lower level than APL. 
Also, its implementation, is more like lISF than 
APL. 

Continued on pg. ?1 
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TEMPORAL ASPECTS OF THE 
FORTH LANGUAGE 

A BEGINNER'S TUMBLING BLOCK 

John M. Derick 
Linda A. Baker 
P.O. Box 553 
Mountain View, CA 94042 



Novice TOFTH programmers v*x5 have 
had previous experience with other, 
more traditional, progranming languages 
almost invariably becane confused vAien 
first dealing with FORTH. A first time 
user sitting down at a FORTH terminal 
soon notices what seem to be time-based 
inconsistencies. That is, the language 
seems to require that things be done in 
the wrong order or that the language 
itself does things out of time order. 
The novice, striving to understand 
these supposed "inconsistencies" 
detects time as a note of commonality 
and therefore lunps them all together 
as one oddity, while in actucdity there 
are three separate areas of difficulty. 

The interesting point of this is 
that the cause of this confusicm is so 
elementary that once the problems are 
understood, it is difficult to look 
back and pinpoint why the confusion 
arose in the first place. This is why 
these elementary problem areas are not 
stressed in most existing FORTH litera- 
ture and are just assumed to be part of 
the longer than normal learning curve 
associated with FXDKTH. Making it clear 
in the neophyte's mind that there are 
three separate, but related, factor 
shortens this learning curve. 



Let us examine what situations cause 
this confusion. 

Sitting at a FORTH terminal, you 
enter a FORTH word, hit a carriage 
return and the word executes. Other 
times, though, you enter a line of 
FCWTH words (including the one you just 
executed previously), hit carriage 



return and nothing executes. But when 
used later on this same word exeoites! 
As you learn wore, you discover that in 
order to perform some functions you 
must actually alter the traditional 
time sequence of programming and modify 
FORTH 's conpiler after it already works 
and is ebugged. Tlien, to add even more 
confusion, you find that scsne vK)vds, 
when added to the compiler, will 
execute different parts of that same 
word at different times. Or, when you 
edit a FORTH program, save it on disk 
and then conpile it; some parts compile 
as expected but other words execute 
immediately. 

To an experienced FORTH programmer 
it is quite obvious that there are 
actually three separate (but releated) 
aspects of PORTO represented in this 
example. To a beginner all of these 
attributes are lumped together in 
one tangled question of "who's on 
first????" and "when did he get 
there????" 

With the exception of different 
parts of a word executing at different 
times, these are very trivial problems 
to an experienced FORM programmer. To 
the beginner they are totally new 
ccxicepts that must be sorted out and 
grasped — even though once understood 
they really are trivial concepts. 

Let us first address the most basic 
of these three time related stumbling 
blocks; that of modifying the compiler. 

Before we continue it is important 
to point out that there are several 
steps (one may almost say laws) that 
always must be followed to generate 
object code from source code. Tradi- 
tional programming languages take these 
steps in a straight line one-pass 
manner. FORTH also takes these same 
steps (i.e., a compiler has been 
written and installed). The difference 
with FORTH however, is that the act of 
writing the compiler is not intended to 
be a cxie-pass step. Instead it is a 
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recursive procedure where the compiler 
IS constantly modified and tailored to 
the users needs over and over again. 
This alters the time sequence of things 
and is a slightly shocking concept but 
the basic rules are still the same. 

In traditional languages a pro- 
grammer goes through several temporally 
separated steps to generate a user 
program: A compiler (or assembler), an 
editor, a link editor and loader are 
all separately created and installed on 
the user's systen. Then the user edits 
a program, compiles it, links it, then 
loads and tests it. Everything is done 
in such absolutely clear cut steps that 
one is subtly led to believe that this 
is the absolute nature of the world. 

TORTH on the other hand is a highly 
interactive, dictionary-based language 
where new additions to the language 
(i.e., user added words) are simply 
added to the end of the dictionary 
thereby "extending" it. FORTH 's 
compiler is part of this dictionary 
and therefore words added to the 
dictionary can actually affect or be 
used in the conpiler. In POPm, this 
is not only possible, it is required if 
one is to fully use the power of the 
language. 

A sinple ccsicept? Yes. But it is 
so contrary to traditional practice 
that it is hard for a neophyte to 
believe advanced documentation which 
tells how to build cornpiler directives 
such as "creating" or "defining" words 
while only alluding to the fact 
that the compiler can and should be 
modified. 

Therefore, let us emphasize this 
fact: The compiler in FORTH is not 
sacred . The traditional sequential 
steps of writing a compiler and forever 
using that particular product do not 
apply in FORTH. FORTH 's compiler may 
be modified at any time. All, or part 
of it may be executed at any time. 
As a matter of fact "creating" or 



"defining" words used in the ccxnpiler 
are actually tiny standalone conpilers 
in themselves and can be used to 
perfonn mini -compilations whenever they 
are referenced. 

Now that this corrpiler moditication 
aspect has been "factored" out of th»- 
jumble of time related "confusions" , 
the beginner is still left with the 
second point of confusion: Namely wtiy 
words sometimes execute iirare-diateiy ar.d 
sometimes do not. 

The technical reason why words 
execute immediately is that the 
"precedence" bit associated with 
that word is set on; but it is the 
philosophical reasoning for the 
existence of the precedence bit that 
is of importance to the neophyte. 

Again all of this is tied in with 
the fact that FORTH 's compiler is an 
integral interactive part of the 
language. It is an integral part of 
the language because it is coiiposed of 
oatmon FORTH words used not only in the 
compiler but in every other FORTH 
application as well. 

Entering a FORSffl word or words on 
a terminal, and hitting carriage 
return causes that word or words to be 
inmediately executed and is similar to 
executing an already compiled and 
linked object module. The dictionary 
is searching until the word is found 
and the definition is executed. To do 
this, the word is preceded by a colon, 
FORTH is put into the compiler state, 
and all words up until a semicolon will 
be compiled (i.e., placed into the 
dictionary for future execution). This 
is similar to inputting source code to 
a FORTRAN cornpiler and getting objecr 
oode out. 

The point being made here is that 
FORTH continuously changes between 
"compiler" state and "execution' 
state. When in compiler state, 
roost input words are compiled, not 
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executed. Notice the word "most". 
Some words are executed while in 
ocanpiler state. These are naturally 
called compiler words. 

These compiler words are identical 
in appearance to any other FORTH word. 
Indeed they actually are simply FORTH 
words with the exception that their 
precedence bit is set. They are 
analogous to assembly language pseudo 
ops or compiler directives. A pseudo 
op (like ORG) in assembly language 
gives direction to or is "executed" by 
the assOTtiler; not the object code. It 
is never executed by the user program. 

Thus, words in FORTH may be "flagged" 
to operate as pseudo ops. That is, 
they may be chosen to execute immedia- 
tely and thereby perform some act of 
compilation upon other words in the 
definition; (even if they are imbedded 
inside of a string of source code — 
just as a pseudo op would do in 
assembly language). This "flag" is 
the precedence bit. When the FORTH 
interpreter detects that this bit is 
set, it will cause it associated word 
to be executed immediately, even while 
in compiler node. Using the word 
IMMEDIATE just after a definition is 
the method used to set the precedence 
bit. 

This is a very powerful feature 
of the FORTH language. It allows 
definitions to execute while in 
conpile mode and since FORTH makes no 
distinction between "supplied" words 
and user written words the compiler 
itself can be added to and improved. 
This feature is called "extendability". 

There are certain defining words 
in FORTH that take the trait of "v*ien a 
word is executed" one step further. 
Conc^tionally advanced word such as 
BUIUDS and DOES allow a definition to 
be constructed so that the first half 
of the word will be used at compile 
time but the second half will execute 
at execution time. 



While it is beyond the scc^se of this 
paper to go into the usage of BUILDS 
and WES type words, it should be noted 
that they exist and really do have two 
separate times of execution. 

The last point of confusion is: When 
words contained in a "loaded" block 
execute immediately instead of com- 
piling (or visa versa). When FORTH 
loads a block, it treats the incoming 
data almost as if it were being read 
from a keyboard. Definitions are 
compiled and put into the dictionary 
as they are encountered in the data 
stream. But, if a word is encountered 
that is not contained inside of a 
definition (whether intentionally 
or not!) that word is executed imme- 
diately, just as if it was entered from 
the keyboard. This is a quite straight 
forward, and quite understandable 
effect once it is pointed out. The 
rule here is to put words to be 
compiled inside of definitions. Leave 
words to be executed immediately 
outside of definitions. 

A good example of word purpxssely 
left outside of a definition is 
DECIMAL. This word is normally used as 
the last word of a loaded block to 
insure that after compilation the 
systan is left in its standard base ten 
state. 

In surranary, the temporal confusion 
that occurs when first using FORTH 
is all quite elementary and under- 
standable — at least in principle. And 
at a beginners stage, principle is very 
important. 

The three general categories; 
modifying the compiler, compiler 
directives using the precedence bit, 
and loading and oonpiling blocks, all 
perform execution at predictable 
times and really do have a direct 
correspondence with traditional 
programming sequences. 
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A GENERALIZED LOOP 
CONSTRUCT FOR FORTH= 



For some time, I have been building 
my own version of a FOKTH-like language 
with direct rather than indirect 
threaded code, running on the 8080. 
Lx3st year I learned that my approach is 
almost identical to that of URTH; this 
is not surprising since the design 
criterion of highest possible execution 
speed was the same. To this end, the 
inner interpreter has one level of 
indirection removed (compared to 
FORTH) and jujTips (as for IF , EI£E , 
LOOP , WHILE , UNTIL , etc.) are 
compiled to their 16 bit absolute 
value, rather than a 16 bit offset. 
All this by way of preface that 
although my "home base" is isolated 
fron the West Coast and my implementa- 
tion of the following viords may not be 
exactly FORTH compatible, yet I feel 
that the concepts presented are new and 
useful in the FORTH environment. 

The article 'FOKTH-SS "CASE" STATE- 
MENT' by Richard B. Main in FORTH 
DIMENSIONS , Volume 1, Nurrioer 5 had a 
catalytic effect in the development 
of these ideas, specifically the 
technique of saving an unknown number 
of addresses on the stack and using 
zero as a marker for the last address. 
It seemed to me that one area to apply 
this scheme with good effect is in the 
BEGIN ... UNTIL and BEGIN ... VHILE 
. . . REPEAT loop constructs which 
currently permit only one exit test. 
This sometimes forces awkward stack 
manipulations to "or" conditions when 
two or mare conditions must be tested, 
any one of which is sufficient to 
terminate the loop. The proposed 
constructs solve this problem, require 
no more lower level CODE words than 
already exist, and add to the elegance 
of the language by rotoving the word 
REPEAT. 

The generalized loop is constructed 
one of two ways: 



There can be any number of WHILE 
words in each loop, including none. 
The meaning of the words BEGIN , 
WHILE , UNTIL , and AGAIN is 
exactly the same as currently under- 
stood; no new concepts need be learned. 
For newcomers to the language (of which 
we all hope for, and in large numbers) 
the learning task is easier because we 
have reduced the number of FORTH basic 
words while at the same time increasing 
the power of the language by permitting 
more powerful combinations of these 
words. This is surely a good direction 
since the human (programmer) mind is 
unsurpassed at manipulating symbols, 
but not in remembering them. 

The Words 

The following definitions v»rk in 
my system. In FORTH, v»*iere XELSE and 
XIF require a compiled offset rather 
than an absolute address, the words 
WHILE , COMPADDS , AGAIN , and 
UNTIL must be changed slightly. 



( GENERALIZED LOOP WORDS - at'GlN WH I l.f. I'NTiL. «r,A I N 



BEGIN HERE 

WHILE LIT XIF , HF«t 

UNTIL DROP LIT XIF , , 

COMPADDS BEING DUP Ir HERt 1. !♦ 

AGAIN LIT XELSE , COMPADDS , 

UNTIL LIT XIF , CuMPADDS . 



i»imf:).atf 

iMIFClATL ■ 
xAP ' i.NJiF 

IMMt ; lATt 



How They Work, Conpile Time 

BEGIN Pushes onto the stack the 
address to which the loop 
should jump, followed by a 
zero. The zero is used as a 
market by the COMPADDS 
word. 

WHII£ (if used) Conpiles a condi- 
tional jump to the tonporary 
address of zero, and also 
pushes the address of the 
temporary address to the 



BEGIN ... WHILE ... WHILE ... WHILE ... UNTIL 
BEGIN ... WHILE ... WHILE ... WHILE ... AGAIN 
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stack. The temporary 
address, which can never 
be zero, will later be 
overwritten by COMPADDS 
with the address of the next 
word immediately after the 
loop structure; this is how 
WHILE effects a loc^ exit. 

UNTIL (temporary) Allows correct 
compilation of the COMPADDS 
word's BEGIN ... UNTIL 
structure. It will shortly 
be replaced with the gen- 
eralized UNTIL . 

COMPADDS Overwrites the address of all 
previous WHILE words until 
the last BEGIN . Each 
address on the stack (there 
may be none) is overwritten 
with the vale HERE+2. The 
zero placed on the stack by 
the last BEGIN terminates 
the overwriting and leaves 
the address of the first word 
in the loop on the top of the 
stack. 

AGAIN Compiles an unconditional 
junp, completes all previous 
WHILE words, and then 
ocxipiles the address of the 
unocaixJitiOTial jump, pointing 
to the top of the loop. 

{JtrriL Identical to AGAIN , except 
a conditional jump is com- 
piled, allowing a conditional 
loc^> exit. 

How They Work, Run Time 

They work the same as the previously 
known BEGIN , VKllE , IWTIL , and 
AGAIN . 

Error Procedures 

Error c*iecks can easily be added to 
these words. This is done as below: 



( l,ENEB*LUED LOOP WORDS HIGIN Ml i 1,1. NNTII. M.kWI I 

1 WITH ERROB PROCEDURES S.S PEK RULl.- i<OLlJVNIi I 

: BEGIN Ht RE 1 ; IMMI IIIATI 

; WHILE 1 -'PAIRS LIT XIF, HKHE 0,1 ; IMUMDAII 

; UNTIL l^ROP l)Rt>P LIT XIE , . IMHtDlAM i C [ »1 I'm ;i Y 

; COHPADDS OEGIN DUP IK Hl.ttl 1* 1' :.WA|- ■ fNllH (1 ItMli 

: AGAIN 1 ,'PAIH;. LIT XliLSt , (_<WrAlil):. , ; IMMllilAV 

: UNTIL 1 'PAIRS LIT Xir , I'l^l'Ai'lv; , ; IMMllMAri 



The operation is self-evident. 

Conclusion 

Generalized loop words BEGIN , 
WHILE , UNTIL , and AGAIN have 
been proposed. Their use provides, 
as a subset, the well known actions 
of BEGIN . . . AGAIN , BFGIN . . . 
UNTIL , and BEGIN ... WHILE ... 
REPEAT (with the word REPEAT 
replaced by AGAIN ). When used in 
this manner the new words impose no 
more run time overhead in time or 
space than the words they replace. 
If the new words did nothing irore, 
they would still be desirable 
because they "orthogonal ize" the 
unconditional loop termination word, 
making it AGAIN regardless of the 
presence or absence of the WHILE 
wDrd. 

But, as an added benefit of the new 
words, more powerful constructs such 
as BEGIN ... WHILE ... UNTIL or 
BEGIN ... V«II£ ... VHIIE ... AGAIN are 
possible. Thus multiple tests and 
exits from a loop can be arranged in 
the most natural order, without the 
need to "or" the results of the tests. 
These multiple loop exits do not 
violate the principles of structured 
programming since they all lead to a 
commDn point; in other words, the loop, 
as a structure, has one entry and one 
exit. 

Future Research 

After much thought about the impli- 
cations of the proposed words in 
relation to the FORTH philosophy of 
programming, I must say that of the two 
dianges wrought by these words, viz. 
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■ .1 .ntlK^qonalization of the loop 

■ -vrruct, and the ability to have 
'-:'itiplo loop exits, 1 believe that 
-1 t ;n>ional i zat ion is by far the nost 
i-iifxntant result. In FXDRTH, while the 
vi'iy Jct of proqramming consists of 
cxt(?n<-iiiX5 ttic lanquaqe by creating many 
tiew words useful in the application 
envi roniDent , even so, I believe that 
the initial basic wards, especially the 
structurec^ proqramminq constructs such 
as IF ... ELSE . . . ENDIF , BEGIN . . . 
UNTIL , and DO . . . LOOP should be as 
few and as general purpose as possible. 

In addition, they should be care- 
fully names so as to convey their 
action to programmers new to FORTH, but 
familiar with similar structures on 
other, "industry standard" languages 
such as ALGOL, PASCAL, and C, The 
construct IF ... ELSE ... THEN is 
poor in this respect; the word THEN 
confuses novices to FORTH since it 
usually implies selection, while in 
this case it is really a construct 
terminator. I assume that this is the 
reason why the change from THEN to 
ENIF was specified in FORTH-79. 
Similarly, BEGIN ... END is confusing 
since it does not imply repetition to 
the average programmer. FORTH-79 
partially corrects this confusion with 
BEGIN .. UNTIL , but I believe sonie 
word signifying repetition should 
replace BEGIN , such as REPEAT ... 
UNTIL , REPEAT ... AGAIN , and REPEAT 
... WHILE ... AGAIN . 

As for DO ... LOOP , this construct 
cries out for a convenient way to 
prematurely exit the loop. LEAVE 
seems weird - at odds with commonly 
accepted practice - since it has a 
deferred effect, caking place only at 
the end of the loop. Although I won't 
remove it from the language, I suggest 
an alternative: Do . . . VJHII£ ... LOOP 

At the execution of the optional 
WHII£ , if the stack is zero the loop 
is exitted. Not possible because 
WHILE is already used for the REPEAT 
... WHILE ... AGAIN loop, you say? 



But it is possible! A very useful 
by-product of the Error Procedures of 
University at Ulrecht, Netherlands is 
that they always leave at the top of 
the stack (during compile time) a 
flag indicating the identity of the 
innermost construct, different for 
REPEAT ... and DO it is then a 

simple matter to arrange WHILE to 
have different actions and to compile 
entirely different CODE words depending 
on this value. Of course, we would not 
limit the number of WHILE words 
between DO and LOOP . LOOP must be 
modified, as was described above for 
AGAIN , to permit this. 

Bruce Komusin 
Ontel Corp. 

250 Cros sways Park Dr. 
Woodbury, NY 11797 



New Product = 



OimiForth, from Interactive Conputer 
Systens, is now available for the North 
Star conpjter. FORTH ccxnbines struc- 
tured programming, stack organization, 
virtual memory, compiler, assembler, 
and file system into an extensible 
macrolanguage. Organized as a dic- 
tionary of words, FORTH allows defining 
new words that extend the vocabulary to 
suit any application. Words are 
conpiled on entry into code ready for 
immediate test, and execute ten times 
faster than Basic. FORTH supports 
coding time-critical routines in 
assembler for the fastest response. 
OmniForth contains the interactive 
FORTH oonpiler (modeled on . Fig-FORTH ) , 
assentiler for the 8080 and 2-80, file 
syston, and text editor. Qmni-Forth 
requires 24K menory and North Star DOS, 
and costs $49.95; an c^tional Intro- 
ductiCMi to FORTH manual is available 
for $15.00. Interactive Computer 
Systems, Inc., 6403 Di^farco Road, 
Tairpa, FL 33614. 
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==FILE NAMING SYSTEM 

Peter H. Helmers 
University of Rochester 



This particular FORTH file naming 
system is set up to use a disk based 
directory to name files which are 
comprised of a series of disk blocks. 
The system does not include any 
specific file formats, but instead is 
used to translate a filename to a block 
number. This block number can be a 
traditional "load block", a directory 
block for a linked set of random data 
blocks, or perhaps the initial block in 
a multi-block text file. Routines are 
available to control a disk's bit map 
of allocated blocks so that already 
utilized blocks are not overwritten. 
Additional routines allow creation of 
filename/block entries at either fixed 
block locations or at random locations, 
or deletion of file entries, directory 
listings, etc. 

The philosophy in writing this 
package was that file formats should 
be user definable although several 
standard uses are being brought up for 
text files, and data arrays stored in 
consecutive blocks. By using the words 
available, additional file formats Cein 
be easily added. 

The file naming system presently 
uses three blocks at the end of each 
disk. The first block contains two 
data arrays: a bit map of block usage 
on the disk, and a list of block- 
pointers for each defined filename. 
The bitmap uses one bit per disk blocJc 
to define v**iether the block is used or 
not; the bit is a "1" if the block is 
used. The block pointer array consists 
of 64 integers which point to the 
filename's starting block number. A 
value of -1 means that the filename is 
undefined. 

The second two blocks contain 64 
filename strings of up to 32 characters 



each. Each name string is actually 
stored as a fixed length 32 byte string 
with any extra characters being padded 
blanks. A non-valid file is flagged by 
a -1 value for the block pointer, not 
by a null of special string. 

The following is a list of the 
primary user oriented words in this 
file naming package: 

("STR") FIND-NAME (INDX) 

FIND-NAME searches for the STR in the 
directory and returns its directory 
index if found, or a -1 if not 
found. Hius a user can test for a 
-1 to see if a filename exists. 

INIT-DIRECTORY 

INIT-DIRECTORY is used to set all 
block pointers to -1 's so that no 
files will be considered to be in 
existence. 

INIT-BIT-»1AP 

INIT-BIT-MAP is used to set all 
bit map bits to O's, thus indicating 
that no disk blocks are being 
used. 

(BIi(#) FREE-BUC 

FREE-BLK is used to reset a given 
block's bit bit, thus indicating 
that it is not in use. 

(BUC#) RESERVE BUC 

RESERVE -BLK is used to set a given 
block's bit map to indicate that it 
is in use.. 

FIND-FREE-BIiC (BIi(#) 

FIND-FREE-BLK is used to find the 
first free block encountered in the 
bit map. It returns a "free" block 
number if one can be found, or a -1 
if the disk is full. 
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("NAME") NEW 

NEW is used to create a new filename 
entry with a block pointer found 
from the first free block en- 
countered in the bit map. 

("NAME"), (BLK#) NEW FIXED 

NEW-FIXED is used to define a new 
filename with a specific block 
pointer (for example, a traditional 
"load block"). 

("NAME") FILE (BLK#) 

FILE is used to translate a filenane 
string to a specific block number. 

("NAME") ERASE 

ERASE is used to erase the given 
filename from the directory. 

DIRECTORY 

DIRECTORY is used to print a listing 
on the console of all defined 
filenames. 



( FILE NAMING SYSTEM - PHH - 30 NOV 79 ) BASf 
0F8 CONSTANT DIB I FILE DIRECTORY BLO.-KS : TMIT 
: INDX- )STB-ADDR " 

20 /MOD 

DIR » 1» 

BLOCK 

SWAP 5 ^-L 



iKWK ■ 

INDX ON TOS ON tNTHY 1 
( 12 FI LFNAMES/HIAXK ) 
( NAMES IN HLKS Dlh< , 1. 1 • < 
i ADDR OP Bl.Cjrk W/ ■^A'^F IN 
( BYTF OFFSFT I NTH HL'HK 
I RTRN AOUH OF NAMF bTHlN^'. 



INDX- >BLK-PTR- ADDR 
t <-L 
DIR BLOCK 



( INDX ON rus 1 

( CREATE BYTE OFFSFT INTO BLOCK 

( ADDR OF BLOCK WITH F I LF POINT 

I RTRN ADDR OK FiL.F'S .U.Or K fNTK 



EKS 



i/i;;^irr^iti^x- varIa^^e'?-;.^:?^ ' 

,^INDX->BLK-PTR-ADDR S^-l^-^^ _ 
■DUP I INDX->SrR-ADDR -GET " • 



IF 

I FILE-INDX 
THEN 
THEN 
LOOP 

"DROP FILE-INDX » 



I NAME MATCH FOIND I 
EXIT ( SET INDX AND FS^AFE 1 
( OTHERWISE I 

( TRY NEXT NAIF CNTBY IF NOT ilONt I 
I REMOVE ~A»r,ET STHIN'; AND ... ) 
( RETURN THE INDX OF THE STRING , 



BASE I 



:S 



FILE NAMING SYSTEM - PHH 
CREATE- NAME 

-1 FILE-INDX ! 

40 DO 

I INDX->BLK-PTR-ADDR 

IF 

I FILE-INDX ! 
I IHDX->STR-ADDR 
■■ UPDATE EXIT 
THEN 
LOOP 

"DROP FILE-IHDX « 



I 



- 11 30 I BASE I" HEX 

( FILE -NAME STRING ON TOS I 
( SET TO INDICATE NO ROOM AVAIL I 
( SEARCH DIRECTORY FOR NULL FILE 

» -1 " 

I NULL, SO PLACE NAME HFRE I 
( SAVE INDX WHERE NAME IS SAVED ) 
•PUT ( SAVE FILE'S NAME IN DIR ) 
( NULL STR TO TOSS, AND EXIT ) 

( UNTIL MATCH OR END OF DIR ) 
( DROP TARGET OR NULL STRING, t 
( RTRN INDX OF NEW FILE I 



BASE 1 :S 



(FILE NAMING SYSTEM - PHH 
: FILE -ERROR 
DOCASE 

DUP 1 » WHEN T" 
CASE DUP 2 = WHEN T" 
CASE DUP 3 ' WHEN T" 
CASE DUP 4 • WHEN T" 
CASE DUP 5 • WHEN T" 

ENDCASE 

CR 

RESTART 

2DR0P ( DO CASE BUG ) 
BASE ! ;S 



12 3 79 ) BASE * HEX 



ALL BLOCKS USED " 
FILE ALREADY EXISTS 
DIRECTORY FULL " 
NAME TOO LONG " 
FILE NOT FOUND " 



, ^iic UAMTNC SYSTEM - PHH - 11 30 79 ) BASE ? HEX 



mDX->BLK-PTR-ADDR 
-1 SNAP ! 
UPDATE 

[ INIT-DIRECTOBY 
40 DO 

I DELETE-FILE 
LOOP 

BASE ! ;S 



, FIND ADDR OF BLK'S POINTER ) 

( FLAG DELETION BY -1 BLK PTR ) 

( FORCE DISK UPDATE ) 

( -DELETE ALL DIR ENTRIES ) 

( INDX ALL 64 DIR ENTRIES I 

( DELETE EACH BY INDX ) 



A Riddle 



FILE NAMING SYSTEM 
PB DO T" " LOOP 
■SPACES O DO " " ■ 
"GET 20 SWAP "#F ; 
"PUT 20 SWAP "!F ; 
FILE-NAME-FIX 

"LEN SUP IE > 

IF 

4 FILE-ERROR 
THEN 

20 -- "SPACES 
UkSE I ;S 



- PHH - 12 4 79 ) BASE t HEX 

I LOOP ; ( ADD ITOSl SPACES TO STRNG I 
( GET 3 2 BYTE STRNG FROH ADDR ON TOS ) 

( PUT 32 BYTE STRNG TO ADDR ON TOS ) 
( MAKE NAME 32 CHARS LONG ) 
( CHECK THAT NAHE <" 30 CHARS ) 

( NPOE, SO GIVE ERROR ) 

( PAD W/BLNKS TO 32 CHARS ) 



FOimi 

Supervisor: 



FCSOH 
Progranner: 



What's the differ- 
ence between 
'ignorance' and 
• indifference ' ? 



I don't know and I 
don't care. 
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FILE 

.;et- 

Dl'P 
7 t. 
SWA 
300 
DIR 
DUP 
ROT 

FREE 
GET 

- t 

C! 



NAMING SYSTEM - PHH 
BIT-MASK 



1 SWAP ^-L 
P 3 ->L 



BLOCK 



-BLK 

-BIT-MASK 
XOR i SWAP 
UPDATE 



- 11 30 79 ) BASE S HEX 

( GET BIT MAP INFO FOR BLKI ON TOS ) 

( GENERATE BITI, THEN BIT MASK ) 

( GEN. BYTE OFFSET IN BIT MAP ) 

( ADD BIT MAP OFFSET W/IN DIB BLK ) 

( DUP IT, AND GET ITS VALUE ) 

( RTRN BIT MAP ADDR, OLD BIT MAP ) 

( BYTE, ( BIT MASK ON TOS ) 

( BLKI ON TOS TO BE FREE ' D ) 

( MASK BLK'S BIT MAP BIT TO ) 

( STORE BACK IN BIT MAP i TO DISK ) 



FILE NAMING SYSTEM - PHH 

FILE 
FILE-NAME-KIX 
FIND-NAME UlIP -1 « 
IF FI LE-ERROR THEN 
INDX- ^HLKkPTR-ADDR J 

ERASE 
FI LE-NAME-FIX 
FIND-NAME DUP -1 = 
IF 5 FILE-ERROR THEN 
DUP DELETE-FILE 
INDX- >BLK-PTR-ADDR S 
FREE-BLK 



i T) ) BASK ti HEX 

I KLATE FILE NAME (IN I'OSS V • HIK 

( KOHt'F i HAH S'VUNt; I KN > 

( KIND NAMK'S DIR 1N!>X ) 

( NAME NUT FOUND IN DIH I 

I GET NAMK';'. lUXK'K » ) 

( AND UKTURN ON TOS ) 

( ERASE NAMK ON TOSS FROM I'll* I 

( FORCE 32 CHAR STRING LENGTH ) 

( GET NAME'S DIR INDX, IF ANY ) 

( NAME NOT FOUND IN DIR ) 

( DELETE FILE GIVEN BY INDX* ) 

( GET THE OLD BLK POINTER ) 

( ...AND FREE IT IN THE BIT MAP 



( FILE NAMING SYSTEM - PHH - 12 3 79 ) BASE » HEX 
: RESERVE-BLK ( MARK BLK ON TOS AS USED ) 

GET-BIT-MASK 

OR SWAP C! UPDATE ( SET BIT IN BIT MASK ) 



INIT-BIT-MAP 

DIR DO 

I FREE-BLK 
LOOP 

SWAP 1* SWAP DO 

I RESERVE-BLK 
LOOP 



( FREE ALL BLKS, THEN RESERVE ) 
( THE RANGE OF BLKS GIVEN ON TOS ) 
( FREE ALL BLKS IN DISK ) 



( RANGE OF BLKS ON TOS ) 

( RESERVE ALL BLKS IN THE RANGE 



( FILE NAMING SYSTEM - PHH - 12 3 79 ) BASE *l HEX 

; DIRECTORY ( PRINT ENTIRE DIRECTORY ) 

40 DO ( CHECK EACH DIR ENTRY ) 

I INDX->BLK-PTR-ADDR 9 (GET BLK PNTR 1 

DUP -1 = ( IS IT AN EXISTANT FILE? ) 

IF ( YES, SO PRINT ITS CONTENTS ) 

I INDX->STR-ADDR ( FIRST, GET THE ADDR OF THE NAME ) 

"GET ". ( PUT IT ON TOSS, AND PRINT IT ) 

5 PB . CR ( PRINT 5 BLNKS, AND THE BLK t ) 

ELSE DROP ( BLK NUMBER ) 
THEN 

LOOP ( CONTINUE FOR ALL POSSIBLE FILES ) 
BASE ! :S 



KILE NAMING SYSTEM 
KIND-FREE-BLK 
- 1 FILE BLK 1 
DIR DO 

I GET-BIT-MASK 
IF 



I FILE-BLK 



THEN 
DROP 

LOOP 

FILE-BLK 9 
^SE ] ;S 



- 12 5 79 ) BASE ? HEX 
( SEARCH BIT MAP FOR FREE BLOCK ) 
( FLAG RESULT FOR NO BLKS POUND ) 
( NOW SEARCH ENTIRE BIT MAP ) 
( IS BLK IN USE? ) 
(NO, ... ) 

( SO SAVE BLK«, AND EXIT L(X)P ) 

( BIT MAP ADDR ) 

( TRY THE NEXT BLOCK ) 

( DONE, SO RETURN THE FOUND BLK ) 

( NOTE, -1 »> NO BLKS FREE ) 



FILE NAMING SYSTEM - PHH 
NEW 

FILE-NAME-FIX 
FIND-FREE-BLK DUP -1 - 
IF 1 FILE-ERROR THEN 
"DUP FIND-NAME -1 " 
IF 2 FILE-ERROR THEN 
CREATE-NAME DUP -1 = 
IF 3 F I LE-ERROR THEN 
SWAP DUP RESERVE-BLK 

SWAP INDX->BLK-PTR-ADDR 
UPDATE 



- 12 3 79 ) BASE d HEX 

( SET UP NEW FILE W/ NAME ON TOSS ) 

( FIRST, FORCE VALID NAME LEN I 

(. MORE ROOM ON DISK? ) 

( NO, ALL BLKS RESERVED ) 

( NAME ALREADY USED? ) 

( YES, GIVE ERROR MESSAGE ) 

( PUT NAME IN DIR, IF NOT FULL ) 

( DIR FULL ERROR ) 

( SET NEW BLK, FOUND BY ) 

( FIND-FREE-BLK, AS RESERVED 1 
! ( STORE FILE'S BLK POINTER ) 

( GO TELL IT TO THE DISK, TOO ! ) 



( FILE NAMING SYSTEM - PHH 
; NEW-FIXED 

FILE-NAME-FIX 
"DUP FIND-NAME -1 ■ 
IF 2 FILE-ERROR THEN 
CREATE-NAME DUP -1 - 
IF 3 PILe-ERHOR THEN 
SWAP DUP RESERVE-BLK 

SWAP INDX->BLK-PTR-ADDR 
UPDATE 

BASE I ;S 



12 3 79 ) BASE $ HEX 



LIKE 'NEW EXCEPT BLK POINTER ) 
GIVEN BY I ON TOS ) 
FORCE 32 CHAR LENGTH ) 
NAME ALREADY EXIST? ) 
YES, SO GIVE ERROR MESSAGE ) 
PUT NAME IN DIR, IF DIR NOT FULL ) 
DIR FULL, SO GIVE ERROR ) 
RESERVE BLK, GIVEN BY I ON TOS ) 
ON ENTRY TO 'NEW-FIXED' ) 
( AND STORE BLKI AS FILE'S PTR ) 
( GO TELL IT TO THE DISK ! ) 



LYONS' DEN 



(Continued from pg. 22) 



Regarding FORTH this way captures some of 
the reasons why FORTH should not be used as 
merely a low level pseudo-machine in the way 
Wirth used P-Code to implement PASCAL, or as 
how meta compilers, as opposed to how a meta 
interpreter works. Of course, any language can be 
used to write an interpreter, but FORTH provides 
tools for this purpose built in and is thus pre- 
structured for that kind of application. This may 
also suggest— as just a possibility— why there has 
been observed markedly less use of conditional 
branches in FORTH programs relative to 
FORTRAN; perhaps many of the conditionals that 
would be explicit in FORTRAN are simply per- 
formed as executions of the interpreter functions 
which perform a complex set of conditional 
branches automatically without having to identify 
them as such. I will wager LISP is the same way. 



George B. Lyons 
Jersey City, NJ 
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TOWERS OF HANOI 

by Peter Midnight 



Here are the listings of a graphic 
representation of the ancient Towers 
of Hanoi puzzle which is adjustable 
for any CRT terminal with curser 
addressing. 

Recently, when I got fig FORTH 
running on my system under ^k^rth Star 
DOS, I decided to translate this 
program into FORTH as an exercise and 
as a comparison between FORTH and 
PASCAL. In the process I noticed sane 
inefficiencies but chose to translate 
them more or less directly, for the 
sake of comparison. 

The UCSP PASCAL program is available 
by requesting the Jan/Feb 1980 News- 
letter from Homebrew Computer Club, 
P.O. Box 626, Mountain View, CA 94042. 



Forth Program 



SCR 



1 

2 



t 12 

; TnWFRS 
( TranFl 
i :-';rst 
: MVr-ELF 
LATES' 
: GOTOXY 
MAX 

: Clears 

: 2 DROP 
: PICK 
: 4DUP 
! C: CON 
VAR 
CON 
VAR 
— > 



OF HANOI Copyright, 1979, Peter Midnight ) 
ated for speed comparison ) PORTH DEFINITIONS DECIMAL 
extend Forth to include a few features of Pascal ) 



recursive use of new 

word ) 

61 EMIT 
63 MIN 32 



EMIT 



{ In definition, this is 
PEA CFA , ; IMMEDIATE 
I X Y GOTOXY ) 27 EMIT 
15 MIN 32 t EMIT MAX 
CkEFN 12 EMIT ; 

DROP DROP ; 
SP3 SWAP 2 • + ? ; 
4 PICK 4 PICK 4 PICK 4 PICK ; 

STANT NMAX { maximuin perinisable number of rings ) 
lABLE (N) : N (N) ? ; ( formerly a constant ) 
STANT HELL_FREEZES_OVER 43 CONSTANT COLOR ( + ) 
lABLE RING N 2 - ALLOT ( array II. .NJ of bytes ) 



SCR 

1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 



» 14 

( TOWERS OF HANOI Copyr^jht, 1979, Peter Midnight ) 

: PRESENCE ( tower ring PRESENCE -> boolean ) 

RING + C9 - ; 
: LINE ( tower LINE -> di spi ay_l i ne_of _top ) 

4 SWAP N DO DUP I PRESENCE 0= ROT <■ SWAP LOOP DROP 
: 1- 1 - ; 

: RAISE ( size tower RAISE ) 

DUP POS SWAP LINE 1 SWAP DO 

2DUP I BL DISPLAY 2DUP I 1- COLOR DISPLAY 

-1 +LOOP 2DR0P ; 

: LOWER ( size tower LOWER ) 



SCR 

1 
2 
3 
4 
5 
6 
7 

e 

9 
10 

11 

12 
13 
14 

15 



DUP 

2DUP 

LOOP 



15 



POS SWAP LINE 1+ 2 Do 

I 1- BL DISPLAY 2DUP I COLOR DISPLAY 

2DR0P ; 



TOWERS OF HANOI Copyright, 1979, Peter Midnight ) 

MOVELEFT ( size source_towet destiny_tower MOVELEFT ) 

POS 1- SWAP POS 1- DO DUP R 1+ 1 BL DISPLAY 

DUP R 1 COLOR DISPLAY -1 +LOOP DROP ; 

MOVERIGHT ( size source_tower destiny_tower MOVERIGHT ) 

POS 1+ SWAP POS 1+ DO DUP R 1- 1 BL DISPLAY 

DUP R 1 COLOR DISPLAY LOOP DROP ; 

TRAVERSE ( Size source_tower destiny_tower TRAVERSE ) 

2DUP > IP MOVELEFT ELSE MOVERIGHT THEN ; 

MOVE ( size source_tower destiny _tower MOVE ) 

7TERMINAL IF N 4 + GOTOXY ABORT THEN 
ROT ROT 2DUP RAISE >R 2DUP R> ROT TRAVERSE 
2DUP RING + 1- CI SWAP LOWER ; 



— > 



SCR 

1 
2 
3 
4 
5 



9 
10 
11 
12 
13 
14 
15 



I 16 

( TOWERS OF KAJJOI Copyright, 1979, Peter Midnight ) 

: MULTIMOV ( size source destiny spare MULTIMOV ) 

4 PICK 1 - IF DROP MOVE ELSE 

>R >R SWAP 1- SWAP R> R> 4DUP SWAP MYSELF 

4DUP DROP ROT 1* ROT ROT MOVE 

ROT ROT SWAP MYSELF THEN ; 

: MAKETOWER ( tower MAKETOWER ) 

POS 4 N + 3 DO DUP I GOTOXY 124 EMIT ( I ) LOOP DROP ; 
MAKEBASE ( no arguments ) 

N 4 t GOTOXY N 6 • 3 + DO 45 EMIT ( - ) LOOP ; 
MAKERING I tower size MAKERING ) 
2DUP RING + 1- C! SWAP LOWER ; 
SETUP ( no arguments ) CLEARSCREEN 

N 1+ DO 1 RING I + CI LOOP 3 DO I MAKETOWER LOOP 
' MAKEBASE N DO 1 MAKERING -1 ♦LOOP ; — > 



SCR 

1 
2 
3 
4 

6 
7 
3 
9 

1 C. 

i; 

12 
1 ! 
14 

15 



TOWERS OF HANOI Copyright, 1979, Peter Midnight ) 

DELAY ( centiseconds DELAY ) 

DO 17 DO 127 127 • DROP LOOP LOOP ; 

POS ( location POS -> coordinate ) 

2N* 1+ • N + ; 

HALFDISPLAY ( color size HALFDISPLAY ) 

DO DUP EMIT LOOP DROP ; 

<DISPLAY> ( line color size <DISPLAY> ) 

2DUP HALFDISPLAY ROT 3 < IF BL ELSE 124 ( I ) 

THEN EMIT HALFDISPLAY ; 

DISPLAY ( size pos line color DISPLAY ) 

SWAP >R ROT ROT OVER - R ( color size pos-size line ) 

GOTOXY R> ( color size line ) ROT ROT <DISPLAY> ; 



SCR 

1 
2 
3 
4 
5 

e 

7 
8 
9 
10 
11 
12 
13 
14 
15 



« 17 

( TOWERS OF HANOI Copyright, 1979, Peter Midnight 
: TOWERS ( quantity TOWERS ) 

1 MAX NMAX MIN (N) ! 

SETUP N 2 1 BEGIN 

OVER POS N 4 + GOTOXY 

ROT 4DUP MULTIMOV 

HELL_FREE2ES_0VER UNTIL 



N DO 7 EMIT 50 DELAY LOOP 



;S 

( Results: DELAY runs much slower in Forth than in Pascal. 
But the rest of the program is over twice as fast in Forthl 

Note that CLEARSCREEN and GOTOXY are terminal dependant. 
NMAX should be 10 for 16x64 or 12 for 24x80 screens. ) 



MSG * 15 



Thanks to "THE I/O PORT", the 
Official Newsletter of the Tulsa 
Computer Society, for the feature 



article on FORTH by Art Sorski in their 
April 1980 issue. Address: The Tulsa 
Computer Society, P.O. Box 1133, Tulsa, 
OK 74101. 
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LETTERS 



I'd like to take this chance to 
accomplish several aims. First, let me 
congratulate Roy Martens and the entire 
editorial staff for a fine publication 
in FORTH DIMENSICNS. 

My interest in FORTH is far from 
passive; I have been using the 'Jniver- 
sity of Rochester's (my employer, by 
the way) URTH dialect for several years 
now. While at first I used it mainly 
at home for a private music synthesizer 
research project, I have more recently 
been applying it with success to 
several laboratories within the 
University's Medical Center. The 
applications have primarily been 
concerned with slow speed (10 to 
100 samples per second) analog data 
acquisition and analysis - the latter 
involving the use of the AMD 9511 IC 
for number crunching (and it is fast 
...!). These data acquisition systems 
have been described in an article which 
I just recently submitted to BYTE for 
publication (I hope). 

While using FOKTH in these appli- 
cations, I have developed a set of 
goals for the elimination of some of 
the limitations of FORTH (there are 
some , you knew . . . ) . One of the major 
problems has been saving only three 
characters plus the length for identi- 
fiers; I have just recently implorented 
changes to adopt (in URTH) the FIG 
standard. Using primarily S-100 
hardware, I am also new implementing a 
hardward debug facility for FORTH vttiich 
allows easier program development. The 
design is very simple, but allows traps 
at instructions, memory references, 
and/or I/O references. I consider this 
method of debugging immeasurably wore 
useful than just software trapping at 
each pass through NEXT. 

Additic«ial FORIH dianges planned are 
the inplementaticm of a random block 



text file system with variable record 
length and blanks conpaction. I feel 
that this system will make it easy to 
write programs in a more readable 
format since this better formatted text 
will use less space than the current 
block oriented text editors. Thus 
there will be less of a temptation to 
use a short, cryptic coding style. My 
method of blanks compaction is to use 
the MSB of each text character to flag 
a compaction count byte. When listing 
a program in the editor, the compacted 
blanks can be re-expanded while they 
can be interpreted as blanks (due to 
changes in the WDRD routine in URIH) 
when loading the text. Text will be 
stored on disk blocks as an integral 
number of lines of text per block with 
eadi line being defined as or mDre 
characters followed by a carriage 
return character. 

Text will be able to span multiple 
random blocks to avoid any "artificial" 
program length constraints due to fixed 
block size. Blocks are associated 
together via a doubly linked (forward 
and backward) pointer scheme while 
block usage is kept track of via a bit 
map (more on this later) corresponding 
to the disk's block utilization. So 
far the text editor has been written, 
but not fully debugged. However, the 
bit map and filing name system has been 
written and used for several months. 
I'd like to discuss them here as 
the type of entity which should be 
standardized for FIG FORTH usage. Let 
me try to motivate this building of 
file structures by analogy to building 
data structures in FOPTH. 

IN FORTH (or at least URTH) one 
can use some systan features to define 
any arbitrary data structure. One 
vi*iich I've used recently is: 

: IPARAM <BUILDS 2 ALL07 DOES > 

v*iich might be used: 

IPARAM MY-VIRTUAL-INTBGER 
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The important things to notice in 
this example are that the IPARAM data 
type first uses standard dictionary 
features to add new specific variables 
- in this case MY-VTRTUAL- INTEGER - tO 
the dictionary. IPARAM also sets aside 
some dictionary space - in this case 
]ust one word - to store data for 
MY-VIRTUAL- INTEGER. Thus there are two 
important actions here - that of 
linking a variable's name into the 
dictionary, and that of reserving 
dictionary space for a variable's 
storage requirements. 

The file system that I have been 
evolving also achieves two analogous 
actions to those above. First, it has 
a way of linking a file's name into a 
diskettes name directory, and second, 
it has a way of reserving disk block 
space for a file's sole use. Note, 
that it doe s n ot concern itself in 
any manner wi t h how the file is 
logically formatted . As such, it is 
not a canplete file management system, 
but only a common protocol for various 
logical file structures! 

Let me explore two uses of file 
types built on this foundation. The 
previously mentioned text file systan 
logically builds a file structure 
by the use of doubly linked random 
blocks. But in another case, the file 
is logically built up as an array 
of consecutive integers in consecu- 
tive disk blocks - thus linked only 
inplicitly. Other logical structures 
are as diverse as are FORTH data 
types. 

In summary, what I am pressing to 
be discussed and hopefully standardized 
is a ocmtnon structure which can be used 
to name files and reserve disk space 
for files. I am not suggesting any 
specific file structures or formats 
for standardization. I am enclosing a 
copy of the source listings and sane 
(hastily written) documentation for 



this file system so that it might 
stimulate comments and improvements 
fran the public domain. 

Thanks very much, and keep up the 
good work .... 

Peter H. Helmers 
University of Rochester 
Rochester, N.Y. 



In Decenber I got tired of waiting 
and implemented FORTH-65 from the 
fig-PORTH model. By the end of Decem- 
ber I had it up and running. This 
version follows the model exactly 
except for printer control, the disk 
kinkage, and the inner interpreter. 

The jump indirect in the inner 
interpreter doesn't always work, JMP 
($XXFF) doesn't work correctly on a 
6502. If a CFA ends in $FF it's 
goodbye FORTH. 

This bus bit after my third re- 
assembly of FORTH-65. The inner 
interpreter I'm now using is con- 
siderably slower (60 cycles) but it is 
reliable. 

I assembled FORTH-65 through the 
disk I/O (SCR #69), Screens 72 through 
92 reside on disk and are compiled 
as needed. What I need now is the 
ASSEMBLER vocabulary. Has anyone done 
any work on a FORTH assembler for the 
6502? 



SCR 

1 
2 
3 
4 
5 
6 
7 

a 

9 

10 

1 1 

! J 
13 
14 

IS 



144 

( RANDOM NUMBER GENERATOR t ) 
DECIMAL 

variablf: skeo 

: irano) seed ? 2s9 • 3 » 52767 and dup seff) ■ 

: RANDOM (RANDl 32767 •/ ; I HANi;K 

;S 



J.E. Rickenbacker 
Houston, TX 
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